By way of illustration and in the interests of simplification, a description will now be given of the prior art and the drawbacks thereof in the aforementioned situation where the network is of the CAN bus type.
It will be remembered that a CAN (Controller Area Network) is a serial bus that allows a plurality of devices, called “control units” and each including a CAN microcontroller, to be connected. This type of bus is mainly used today in the industrial field and in the car manufacturing field.
Typically, in a car, two CAN buses are used. One, known as a high speed (up to 1 Mb/s) CAN bus, allows control units to be interconnected that relate to the following elements or functionalities: instrument panel, engine, braking system (anti-lock), active suspension, transmission, etc. The other, known as a low speed (up to 125 kb/s) CAN bus allows control units to be interconnected that relate to the following elements or functionalities: instrument panel, lighting, air-conditioning, inflatable safety bags, door locking, electric windows, etc.
Each CAN bus implements a protocol of the same name (CAN protocol) which is a serial communication protocol supporting real-time systems with a high level of reliability in a restricted and harsh environment such as a factory, a workshop, car etc. The CAN protocol covers two of the seven layers of the open systems interconnection model (OSI) of the ISO, namely the physical layer (layer 1) and the data link layer (layer 2). For more information about the CAN bus, reference may be made to ISO standard 11898, inserted here for reference purposes.
The data link layer of the CAN protocol is such that each control unit is able to send and receive data. The data is carried on the bus in the form of asynchronous packets (also known as frames or messages) of specified format but of variable and limited length. As soon as the bus is free, any control unit connected to the bus is able to send a new packet. An interrupt mechanism for higher priority packets is provided, as well as a mechanism for settling conflicts arising from the simultaneous transmission of several packets on the bus when it is free.
Traditionally, when it is desired to connect a new control unit (in other words a new device including a CAN microcontroller which executes an application (layer 7 of the OSI model)) to a CAN bus, the following procedure is followed. The developer of the application executed by the CAN microcontroller must know the clock frequency of the CAN microcontroller (for example 12 MHz). He assumes furthermore that the throughput of the network takes one of a limited number of values (three values generally). For example, he assumes that the network throughput is equal to 100, 250 or 500 kb/s. For each of the three assumed values of the network throughput, he determines initially, and from knowledge of the clock frequency of the CAN microcontroller, a throughput configuration for the CAN microcontroller. He then develops the application in such a way that, in operation, the application loads a first throughput configuration associated with a first assumed value of the network throughput; if the application receives error messages, it loads a second throughput configuration associated with a second assumed value of the network throughput; and so on in such a way as to test (if necessary) the different pre-set throughput configurations.
One drawback of the aforementioned known technique is that it cannot be employed in situations where the clock frequency of the CAN microcontroller is unknown.
Another disadvantage of the aforementioned known technique is that it does not work if none of the network throughput assumptions is correct.
Yet another drawback of the aforementioned known technique is that, when several possible throughput configurations are tested successively, the CAN microcontroller actually upsets the CAN bus. This may even lead to the CAN microcontroller being ejected from the CAN bus.